An OSH software RFP: requirements, scoring and a demonstration script
An RFP, or request for proposal, allows several suppliers to respond to the same business need. For OSH software, its value lies in turning phrases such as “comprehensive management” and “easy to use” into concrete tests. The document can remain concise if it defines scope, enables comparison and supports an evidence-based decision.
Before writing it, agree which workflows are included in the purchase. The Explora entry on OSH software provides a starting point. Your RFP should translate that scope into your organisation’s operation. Involve safety professionals, operational users, IT and procurement from the outset.
Describe the work problem first
Explain the current situation without turning it into a list of brands or technical preferences. For example, actions arrive in reports, are distributed by email and lack a shared view of progress. Then describe the required outcome: each action needs an owner, deadline, evidence and closure review.
Add the dimensions of the operation: legal entities, sites, roles, languages and source systems. Separate current needs from future scenarios. If expansion is possible but not approved, request a separately priced option instead of treating it as mandatory initial scope. This keeps suppliers’ assumptions visible and comparable.
Write requirements that can be tested
Give each requirement an identifier, process, priority, description, test and assessment owner. A “yes” answer is insufficient. Ask whether delivery is available now, requires configuration, needs development or falls outside the proposal. Dependencies and conditions should appear beside the answer, not in an unrelated presentation.
- Operational requirement: assign an action to an owner and verify closure with supporting evidence.
- Test: create it, change the deadline with a reason and inspect the available history.
- Access requirement: restrict each role to its authorised locations.
- Test: try to view another site’s record using a demonstration account.
- Exit requirement: retrieve the data and documents covered by the contract.
- Test: review a sample export together with its field definitions.
The Explora entry on digital evidence in occupational risk prevention helps clarify what you need to preserve. These are proposed evaluation tests, not claims about the features of a particular solution.
Separate essential conditions from scored criteria
An essential requirement should be an acceptance condition. Inadequate access controls should not be offset by an attractive interface. Define how partial responses will be treated and which evidence will resolve them. Apply the same approach to every participating supplier and document exceptions explicitly.
For scored areas, consider functional suitability, usability, implementation, integration, support and total cost. Weight them according to your organisation’s priorities and agree the reasoning internally before reviewing offers. There is no universal weighting model that suits every company or operating environment.
Record both the score and its explanation. A favourable impression during a presentation is different from a user completing a task. When two options have similar results, review the evidence behind the difference instead of introducing decimal precision that does not reflect a meaningful judgement.
Use a shared demonstration script
Provide a fictional scenario with one site, several jobs and an outstanding action. Ask suppliers to follow it from data entry to the final report, including an owner change and an exception. Allow a member of your team to complete part of the workflow independently.
Include a connection to HR data if integration is in scope. The Explora entry on ERP and HR integration supports questions about data origins, updates and errors. Use synthetic information rather than real personal records in a commercial demonstration. Note any steps completed outside the proposed application so their effort is included in the comparison.
Finish with clear commitments
The RFP outcome should record included scope, exclusions, milestones, deliverables and resolved questions. Connect important commitments to a contract or project document. Preserve the requirement version used for the purchasing decision so that later changes require an explicit decision instead of becoming an informal assumption.
Complete the assessment with the guides to total software cost and implementation planning. When considering Sabentis OSH software, use the RFP to request a demonstration focused on your workflows and a proposal whose commitments your team can verify.
A practical checklist before issuing the RFP
Review the document from the perspective of both the supplier answering it and the team accepting the solution. Ambiguous questions often produce proposals that cannot subsequently be compared consistently.
- Remove duplicate requirements and assign a stable identifier to follow each response through to its acceptance test.
- Require future functions to be distinguished from those already available in the version that would be contracted.
- Define how an exception to a mandatory requirement will be handled and who can authorise it before scoring.
- Include a common process for distributing clarifications to every supplier participating in the comparison.
- Check that the pricing schedule uses the same sites, roles, volumes and deliverables as the functional demonstration script.
Frequently asked questions about an OSH software RFP
Is an internal RFP equivalent to public procurement specifications?
No. A company’s request for proposals can organise a commercial comparison, but it does not replace the documents or procedures required for public procurement. Where those rules apply, the procurement team must adapt the formal file and its evaluation criteria to the relevant requirements.
How should a function promised for a future version be evaluated?
Record it as an outstanding commitment with a date, scope and acceptance condition. Do not score it as available when it cannot yet be demonstrated. If it is essential for launch, the contracting decision must explicitly resolve that dependency and the consequences of delay.
How many requirements should the document contain?
Enough to support an evidence-based decision without turning every visual preference into a purchasing condition. Prioritise complete workflows and relevant exceptions. Each requirement should justify a need and a test; if nobody can verify it or explain its effect on the decision, revise or remove it.
What personal-data information should the proposal include?
Ask for the data processed, the parties’ roles, access, subcontracting and service exit arrangements. Where the GDPR applies, specify processing terms under Article 28. Contractual assessment should reflect the actual operation rather than relying solely on a standard document supplied without explanation.
Legislation and sources consulted
- NIST SP 800-146: Cloud Computing Synopsis and Recommendations: NIST technical guidance for assessing cloud opportunities, risks and service terms; a methodological reference, not Spanish or Colombian legislation.
- European Union: General Data Protection Regulation: Article 28: guarantees and terms where a provider processes personal data on a controller’s behalf within the regulation’s scope.
Sources consulted on 6 October 2026. Checklists and examples are practical implementation proposals.
